Service oriented architecture (SOA) is a computing architecture in which services (e.g., web services) are made available for use by applications. Typically, services comprise programming functions (i.e., software components) and applications comprise programs that call the services and receive data results from the called services. In this manner, an author of an application need not write new code to perform functionality if that functionality is already available as a service. Instead, the author may arrange for the application to call the service and receive the results from the service. For example, an application associated with a retail store point of sale terminal may require that a purchaser's credit card information be verified at the time of presentment of the credit card. Instead of including code to perform such a function in the application, the application may call an already existing service that performs the verification and returns the results to the application. The entity that provides the service may charge a fee for performing the service.
A standard protocol (e.g., XML) is typically used for communication amongst applications and services. In this way, services can be offered to applications independent of an individual application platform or programming language. Owing to this generic availability, service repositories currently exist on networks (intranet and Internet) and are available for use by multiple and diverse applications.
A particular implementation of SOA is a web services environment, in which users of services (i.e., service users) and providers of services (i.e., service publishers) are linked by a communication network (e.g., the Internet). One of the biggest challenges in web services environments is for service users to find a service that they need, and, conversely, for service publishers to inform service users of their available services. For example, a service user desiring a particular functionality for an application may have to consider thousands of published services to find an acceptable service for the task at hand. To facilitate the matching of service users and service publishers, industry initiatives, such as the Universal Description, Discovery, and Integration (UDDI) specification, have been developed for publishing and finding metadata about published services.
The UDDI specification is an XML-based registry that allows businesses (i.e., service publishers) to list themselves and their published services on the Internet, and consumers (i.e., service users) to find and execute published services. UDDI currently includes three components (a white pages, yellow pages, and green pages) that contain information about the registered businesses and the web services they offer. For example, the white pages includes identity information, such as a service publisher's name, contact information, etc. Additionally, the yellow pages includes information that organizes published services by industry category. Lastly, the green pages contains technical information (such as URL location, execution instruction, etc.) about published services.
The information contained in a UDDI registry is stored and maintained (for example, in a database) by a UDDI provider. The registry is searchable in known manners by applying search criteria to various combinations of data fields of the white, yellow, and green pages. Depending on the degree of specificity of a search query, a search may return a list of published services for a service user to review. In this manner, a service user may locate and execute services. Moreover, a service publisher may receive payment for the use of published services.
However, all of the information available in the UDDI registry is provided by the service publishers and/or by the UDDI provider. There is no information provided by service users that could help other service users decide which services to use.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.